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PROCEDE DE COMMUNICATION ENTRE DEUX UNITES. 
ET COMPOSANT LOGICIEL DE CONFIANCE POUR SA MISE EN CEUVRE 

La presente invention concerne les terminaux informatiques personnels 
permettant a des utllisateurs d'acceder a des services en ligne. 

5 De tels terminaux peuvent notamment etre des telephones utilisant le 

protocole duplication sans fil (WAP, "wireless application protocol"), des 
ordinateurs de bureau, des ordinateurs portables ou des assistants numeriques 
personnels (PDA, "personal digital assistant"), lis ont en commun la 
caracteristique d'etre relies a un reseau de donnees numerique, qui dans 

10 beaucoup de cas pratiques est un reseau fonctionnant selon le protocole IP 
("Internet protocol"), notamment I'lnternet. 

, i 

. ■ "A, 

Dans ces terminaux, il est possible d'installer diverses applications.^ 
Parmi ces applications, il est frequemment fait une distinction selon divers 
criteres tels que leur origine, le degre de confiance qui leur est accorde par un 
15 administrateur, etc., qui resulte en des capacites differentes pour certainesj 
applications par rapport a d'autres. [ - 

Par exemple dans les systemes fonctionnant sous le systeme 
d'exploitation dit "Unix", les droits d'execution des applications de classe 
"setuid root" sont les droits maximaux, de niveau administrateur, alors que les 

20 droits d'execution des autres applications sont simplement les droits de 
I'utilisateur qui lance I'application. Autre exemple, dans les navigateurs web 
comportant une machine virtuelle Java, les applications, appelees "applets", 
telechargees depuis un site web donne sont limitees quant a leurs capacites 
d'acceder au reseau, c'est-a-dire qu'elles ne peuvent emettre des requ§tes du 

25 protocole HTTP ("hypertext transfer protocol") que vers ce site web. 

Certains de ces droits d'execution des applications sont purement 
locaux. C'est le cas par exemple du droit de prendre le contr6le de I'ecran d'un 
terminal, ou du droit d'avoir connaissance de toutes les touches enfoncees sur 
le clavier du terminal, meme pour d'autres applications. 

30 Mais d'autres droits d'execution sont observables a distance. C'est le 
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cas par exemple du droit d'emettre des paquets IP quelconques, y compris des 
paquets IP qui ne se conformeraient pas aux formats des protocoles de 
transport les plus courants, a savoir TCP ("transmission control protocol") ou 
UDP ("user datagram protocol"). Dans les systemes Unix, ce droit n'est pas 

5 donne aux applications qui ne sont pas de classe "setuid root". En utilisant 
cette difference de capacite d'envoi de requetes, un observateur a distance tel 
qu'un serveur peut determiner qu'un paquet donne a ete emis par une 
application de classe "setuid root": s'il observe que ce paquet ne se conforme 
pas au format TCP ou UDP, il s'agit forcement d'une application de classe 

10 "setuid root"; sinon, il se peut qu'il s'agisse d'une application sans droits 
privilegies. 

Dans le cas des applets dans les navigateurs, sur les ordinateurs 
personnels, les capacites d'envoyer des requites HTTP sont limitees au seul 
site d'ou I'applet a ete telechargee. Pour chaque requete HTTP recue, un 
15 serveur web peut done deduire qu'elle provient soit d'une applet presente sur le 
site soit d'une autre application (par exemple le navigateur). Mais en tout cas, 
les requetes recues par un serveur web ne proviennent pas d'applets 
"etrangeres" presentes sur d'autres sites. 

On s'interesse ici au probleme de savoir comment un serveur peut 
20 recueillir de facon securisee I'accord de I'utilisateur sur une question donnee. 
La question a poser a I'utilisateur doit §tre presentee a I'utilisateur par 
I'intermediaire d'une application sur son terminal. L'application recueille I'accord 
(ou le disaccord) de I'utilisateur, puis transmet une indication correspondante 
au serveur. 

25 Le serveur recoit done des messages sur le reseau et les interprete 

comme I'accord (ou desaccord) de I'utilisateur. II doit pour cela faire 
I'hypothese que l'application a bien presente la question a I'utilisateur et a 
recueilli son accord en toute honnetete. Le serveur suppose done que 
Tapplication n'est pas un "cheval de Troie" qui aurait par exemple presente une 

30 question differente a I'utilisateur, ou bien qui n'aurait tout simplement pas 
presente la question a I'utilisateur mais fait comme si celui-ci avait ete d'accord. 
Pour proteger I'utilisateur contre d'eventuels programmes du genre "cheval de 
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Troie", il importe de s'assurer de cette hypothese de confiance. 

II existe plusieurs moyens de satisfaire raisonnablement cette 
hypothese de confiance en I'application. 

Certaines applications sont reconnues etre "de confiance". Une telle 
5 application est par exemple le navigateur WAP. Un serveur peut avoir 
confiance en un navigateur WAP pour qu'il affiche une page posant une 
question a I'utilisateur et attende que I'utilisateur saisisse sa reponse. 

Dans le cas d'un terminal "ferme" (exemple: un Minitel), les 
applications presentes sur le terminal sont connues et ne peuvent pas etre 
10 changees au cours de la vie du terminal. Toutes ces applications sont 
reconnues "de confiance". 

L'ouverture d'un terminal fait reference a la possibilite offerte d# 
I'utilisateur d'installer, et souvent de telecharger, de nouvelles applications-* 
destinees a etre executees par le terminal lui-meme. Des exemples de $ 
15 terminaux "ouverts", integrant cette possibilite, sont: vf- 

• les telephones a telechargement d'applications, par exemple de type iV 
Java MIDP ("Mobile Information Device Profile", Sun Microsystems, Inc.); 

• les navigateurs possedant des fonctionnalites dites de scripting, par 
exemple de type WMLScript (voir "WAP WMLScript Language 

20 Specification", version 1.1, WAP Forum, novembre 2001 ) ou ECMAScript 

(aussi appele JavaScript, voir "ECMAScript Language Specification", 
Standard ECMA-262, 3 e edition, decembre 1999), ou accueillant des 
applets; 

• la plupart des PDA, fonctionnant sous les systemes d'exploitation 
25 PalmOS, WindowsCE, Symbian etc.; 

• les ordinateurs de bureau ou portables. 

Les terminaux "semi-ouverts" sont les terminaux ouverts dont certaines 
fonctionnalites ne sont pas directement accessibles aux applications installees 
par I'utilisateur ou telechargees. Par exemple, dans un terminal dont la seule 
30 "ouverture" est ECMAScript, les applications telechargees ne peuvent pas 
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acceder a toutes les fonctionnalites du reseau (par exemple, emettre des 
paquets IP quelconques). Ces fonctionnalites peuvent etre accessibles de 
facon indirecte et controlee. Par exemple, une fonction ECMAScript peut 
commander ie chargement d'une page via HTTP, ce qui utilise le reseau mais 
5 d'une facon controlee. 

Dans des terminaux "semi-ouverts", il y a coexistence: 

• ^applications considerees comme "de confiance", par exemple parce 
qu'elles ont ete installees en usine par le fabricant du terminal, ou bien du 
fait de la garantie procuree par des moyens tels que la signature 

10 electronique de I'application etc.; 

• et d'autres applications qui peuvent etre installees sur le terminal par 
I'utilisateur lui-meme, a son libre choix, mais n'accedent pas aux memes 
droits que les applications de confiance. 

Les terminaux "completement ouverts", par opposition, sont les 
15 terminaux ouverts dans lesquels toutes les fonctionnalites sont accessibles aux 
applications telechargees. La notion d'ouverture d'un terminal depend dans 
une large mesure du contexte dans lequel on se place. Par exemple, 
differentes couches du modele OSI (lien / reseau / session / transport / ...) 
peuvent avoir differents degres d'ouverture. 

20 On s'interesse ici aux fonctionnalites observables a distance, depuis un 

serveur, c'est-a-dire aux fonctionnalites de reseau. Dans ce cadre, le caractere 
"semi-ouvert" d'un terminal implique generalement que des droits d'execution 
observables a distance, accessibles aux applications de confiance, ne sont pas 
accessibles aux applications sans confiance (par exemple, le droit d'emettre 

25 des requetes autres que HTTP sur un reseau IP). Ceci permet a un serveur de 
distinguer, parmi les requetes qui lui arrivent, celles qui proviennent 
d'applications de confiance et celles qui proviennent d'autres applications. 

Les "applets", que I'utilisateur installe a son libre choix, ne sont pas 
forcement de confiance pour acceder a n'importe quel serveur. Cependant, la 
30 restriction des requetes de chaque applet au site d'ou elle a ete telechargee 
permet a un site web de garder le controle sur les applets qui peuvent emettre 
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des requetes vers lui. II est done raisonnable que le serveur suppose que les 
applications presentant des questions a I'utilisateur ne sont pas des Ghevaux 
de Troie. Ces applications sont done "de confiance", mais pour un site web 
uniquement 

5 Dans les terminaux ouverts, il faut tenir compte de la possibilite qu'un 

programme se comporte de fagon trompeuse vis-a-vis de I'utilisateur (cheval 
de Troie). Ainsi, rien ne peut garantir a un serveur qu'une requete provient bien 
de I'utilisateur, et non d'un programme ayant simule I'accord de I'utilisateur au 
niveau du reseau. Ce risque ruine la confiance que le serveur peut avoir dans 
10 les donnees qu'il recoit d'un client. L'hypothese selon laquelle les requetes 
adressees au serveur refletent les actions de I'utilisateur n'est pas raisonnable 
si un cheval de Troie a la possibilite de les envoyer a la place de I'utilisateur. 

■% 

La reponse classique au risque de cheval de Troie est de limiter les 
capacites des applications sans confiance. 

"* 

15 La limitation de remission des trames depuis les terminaux semi* 

ouverts se fait generalement de facon extremement stricte. Seules les 
applications de confiance sont autorisees a emettre certaines trames. Cette 
distinction est utilisee pour que le serveur n'accepte pas commd 
representatives de I'accord de I'utilisateur des trames emises par des 

20 applications sans confiance, susceptibles de trahir I'utilisateur. 

II devient done impossible a une application sans confiance d'emettre 
des trames vers un serveur. II est notamment impossible pour cette application 
de prouver a ce serveur I'accord de I'utilisateur. Par exemple, il est impossible 
a une application sans confiance de proposer a I'utilisateur de payer en utilisant 
25 un serveur de commerce electronique. 

Pour une « applet », qui est restreinte a ne pouvoir emettre des 
requetes que vers le site web d'ou elle a ete telechargee, la confiance n'est 
accordee que pour ce serveur. II est done possible a cette applet de recueillir 
I'accord de I'utilisateur et de transmettre le resultat au site web d'ou elle a ete 
30 telechargee. On fait alors l'hypothese — raisonnable — que le serveur n'a 
jamais propose de telecharger des applications de type "cheval de Troie". 




-6- 

Des systemes a base de cryptographie existent pour generer des 
signatures electroniques. Un exemple en est decrit dans la specification "WAP 
WMLScript Crypto Library", WAP Forum, juin 2001 . Ces systemes peuvent etre 
utilises pour recueillir I'accord de I'utilisateur, ils font I'hypothese que le 

5 systeme est semi-ouvert, c'est-a-dire en I'occurrence que les fonctions d'acces 
aux cles cryptographiques ne sont pas directement disponibles aux 
applications sans confiance. L'acces aux cles cryptographiques est gere par un 
composant logiciel particulier, que nous appelons "composant de signature 
electronique", charge de recueillir I'accord de I'utilisateur pour le compte de 

10 I'application. Ce composant effectue de lui-meme I'enchaTnement d'operations 
suivant pour le compte d'applications sans confiance: 

• afficher le texte a signer a I'ecran; 

• attendre confirmation de I'utilisateur; 

• si une confirmation est recue, utiliser les cles cryptographiques de 
1 5 I'utilisateur pour signer le texte affiche; 

• sinon, ne pas signer le texte affiche. 

Ceci permet done a des applications sans confiance d'obtenir une 
signature electronique de I'accord de I'utilisateur via le composant de signature 
electronique. Ce precede permet au serveur d'obtenir I'accord de I'utilisateur 
20 par rapport a un texte quelconque. 

II faut ici faire I'hypothese que le terminal n'est pas completement 
ouvert. S'il etait possible a une application sans confiance d'acceder 
directement aux fonctions cryptographiques, on ne pourrait pas savoir si I'appel 
aux fonctions cryptographiques a bien ete precede d'un affichage de la totalite 
25 du texte a signer ou si le terminal a bien attendu I'accord de i'utilisateur avant 
de proceder a la signature. 

D'autre part, ce precede met en oeuvre des techniques 
cryptographiques, qui peuvent s'averer coQteuses en temps d'execution, en 
taille de messages echanges sur le reseau ainsi qu'en consommation 
30 electrique (important pour les terminaux portables). De plus, la legislation sur 
les techniques cryptographiques peut eventuellement restreindre la possibilite 
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de recourir a ce procede. 

II est done souhaitable de foumir un comportement quasiment 
equivalent en termes d'ouverture aux applications sans confiance, mais sans 
recourir a la cryptographie. 

5 Un but de la presente invention est de permettre a une application 

"sans confiance" en milieu semi-ouvert de recueillir I'accord de I'utilisateur sur 
une question donnee, et d'en avertir un serveur distant en lui prouvant que cela 
a ete fait de facon honn§te. 

L'invention propose ainsi un procede de communication entre une 
10 premiere unite et une seconde unite par I'intermediaire d'un reseau de 
telecommunication, dans lequel la premiere unite comporte une premiere 
famille d'applications et une seconde famille d'applications ayant des capacity 
de communication sur le reseau au-dela des capacites de communication des ; . 
applications*de la premiere famille. Selon l'invention, ce procede comprend les ; 
15 etapes suivantes: 

/a/ un composant de confiance appartenant a la seconde famille 
d'applications obtient I'enonce d'une question a poser a un utilisateur 
de la premiere unite dans le cadre de I'execution d'une application de" 
la premiere famille; 

20 Ibl le composant de confiance presente la question par I'intermediaire 
d'une interface d'utilisateur et recueille une reponse de I'utilisateur; et 
Id pour au moins un type de reponse de I'utilisateur, le composant de 
confiance transmet a la seconde unite, par I'intermediaire du reseau, 
au moins un message identifiant la question presentee et indiquant la 

25 reponse recueillie, ledit message etant transmis dans des conditions 

inaccessibles aux applications de la premiere famille. 

Un autre aspect de la presente invention se rapporte a un composant 
logiciel de confiance pour la mise en ceuvre du procede ci-dessus au niveau de 
ladite premiere unite, ainsi qu'un terminal de communication, incorporant un tel 
30 composant logiciel de confiance. Ce composant de confiance appartient a la 
seconde famille d'applications precitee et inclut des instructions pour 
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commander les etapes suivantes lors de son execution dans la premiere unite: 
/a/ obtenir I'enonce d'une question a poser a un utilisateur de la premiere 
unite dans le cadre de I'execution d'une application de la premiere 
famille; 

5 Ibl presenter la question par I'intermediaire d'une interface d'utilisateur et 

recueillir une reponse de rutilisateur; et 
Id pour au moins un type de reponse de I'utilisateur, transmettre a la 

seconde unite, par I'intermediaire du reseau, au moins un message 

identifiant la question presentee et indiquant la reponse recueillie, ledit 
10 message etant transmis dans des conditions inaccessibles aux 

applications de la premiere famille. 

D'autres particularites et avantages de la presente invention 
apparaTtront dans la description ci-apres d'exemples de realisation non 
limitatifs, en reference aux dessins annexes, dans lesquels les figures 1 et 2 
15 sont des schemas d'un systeme mettant en ceuvre I'invention. 

On cherche a permettre a une unite distante telle qu'un serveur 1 
d'obtenir de facon sQre et soupie Taccord de I'utilisateur d'un terminal semi- 
ouvert 2 relativement a une question donnee. L'accord peut etre obtenu par 
des applications de confiance 3, comme dans le cas de la navigation, mais 
20 aussi depuis des applications sans confiance 4, ayant des capacites de 
communication plus restreintes (voire inexistantes) sur le reseau de 
telecommunication R utilise pour dialoguer avec le serveur 1 . 

On se place ici dans le cadre d'un terminal 2 faisant une distinction 
entre applications de confiance 3 et applications sans confiance 4. Cette 
25 distinction se traduit par des capacites distinctes d'emission de trames ou de 
requetes sur le reseau R. Les applications sans confiance 3 sont limitees dans 
les trames qu'elles peuvent emettre, ce qui, dans le schema de la figure 1, est 
symbolise par une couche de contrdle 5 faisant partie des ressources 6 
d'acces au reseau dont est equipe le terminal 2. 

30 La couche de controle 5 verifie que certaines proprietes sont remplies 
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par les frames emises par les applications sans confiance 4. Si ces proprietes 
sont remplies, la couche de contr6le laisse passer les frames. Sinon, elle peut 
sort ne pas les laisser passer vers le reseau R et en prevenir I'application sans 
confiance 4 qui les a emises, sort modifier les frames pour les conformer aux 
5 contraintes des applications sans confiance. Dans ce dernier cas, la trame perxJ 
alors sa credibilite aux yeux du serveur 1 , qui ne I'exploitera pas. 

L'invention tire parti de cette couche de contrdle 5 (dont la presence 
peut n'etre qu'implicite et resulter de proprietes du systeme d'explortation ou 
plus generalement de I'environnement d'execution des applications dans le 
10 terminal semi-ouvert) pour empecher une application sans confiance 4 
d'emettre elle-meme des requetes qui prouveraient a un serveur I'accord de 
I'utilisateur relatif a la question posee. Une telle application ne peut done pas 
elle-meme recueillir I'accord de I'utilisateur sous une forme exploitable par ll 
serveur 1 . ^ 

15 On introduit ainsi dans le terminal 2, entre I'application sans confiance, 

le serveur et I'utilisateur, un composant logiciel de confiance 8 dont on s'est 
assure au prealable du comportement "honnete". En pratique, cette assurance 
proviendra souvent du consfructeur du terminal semi-ouvert. Le composant de 
confiance 8 ne peut pas etre remplace ou modifie par une application sans 

20 confiance, ce qui est assure par le systeme semi-ouvert lui-m§me, pour qui une 
application de confiance doit rester de confiance. II n'y a done pas de risque 
que le composant 8 se comporte en cheval de Troie. Un role principal du 
composant de confiance 8 est de recueillir I'accord de I'utilisateur pour le 
compte d'une ou plusieurs applications sans confiance 4, au moyen d'une 

25 interface utilisateur 9 du terminal. 

Le composant de confiance 8 n'est pas limite dans les requetes qu'il 
peut emettre, ou du moins il subit des restrictions moins severes que les 
applications sans confiance 4. Dans I'exemple schematise par la figure 2 ci- 
dessus, il n'est pas controle par la couche de controle 5. 

30 On s'interesse a une application 3 ou 4 qui desire prouver a un serveur 

distant 1 qu'elle a obtenu I'accord de I'utilisateur pour une question donnee. 
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Elle dispose initialement de I'enonce de la question ainsi que d'une donnee 
d'adressage permettant de contacter le serveur distant, par exemple une 
indication de type URL ("Uniform Resource Locator"). 

Les communications de ces applications 3, 4 sont soumises aux regies 
5 suivantes: 

- les applications peuvent effectuer des communications distantes par 
I'intermediaire des ressources 6 et du reseau R, mais ces 
communications sont limitees par le systeme d'exploitation semi-ouvert 
qui incorpore une couche logique de controle 5; 

to - tout serveur distant 1, ayant connaissance des limites appliquees, peut 

determiner si les messages qu'il recoit proviennent d'applications de 
confiance ou non, en examinant si les limites sont appliquees; 

- le composant de confiance 8 a la possibility d'effectuer des 
communications hors des limites imposees aux applications sans 

15 confiance 4, mais aussi dans ces limites s'il le souhaite. II peut a cet 

egard etre vu comme appartenant a la meme famille que les applications 
de confiance 3. 

Une application sans confiance qui desire obtenir I'accord de 
I'utilisateur sur une question donnee et prouver cet accord a un serveur distant 
20 1 fournit au composant de confiance 8 I'enonce de la question ainsi que 
I'adresse du serveur. Le composant de confiance 8 presente alors la question a 
I'utilisateur au moyen de Interface 9. La decision de I'utilisateur (accepter ou 
refuser, I'absence de reponse passe un certain delai pouvant etre interpretee 
comme un refus) est recueillie par le composant de confiance. 

25 Si la decision recueillie est un accord, une requete hors des limites 

appliquees aux applications sans confiance est envoyee par le composant de 
confiance au serveur a I'adresse precedemment indiquee par l'application 4. 
Cette requete contient: 

- I'enonce de la question 

30 - la reponse de I'utilisateur 
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Le serveur 1 verifie, implicitement ou explicitement, que ia requete a 
bien ete transmise hors des limites appliquees aux applications sans confiance, 
et repond a cette requete apres validation. La reponse a la requete est 
finalement transmise par le composant de confiance 8 a I'application sans 
5 confiance 4. 

En cas de desaccord de I'utilisateur observe par le composant de 
confiance 8, celui-ci peut transmettre directement a I'application 4 une reponse 
indiquant I'echec. La reponse negative de I'utilisateur n'est qu'optionnellement 
transmise au serveur 1 dans ce cas. 

10 S'il fait confiance au "composant de confiance" 8, le serveur distant 1 

est assure que les requetes hors limites qu'il recoit correspondent bien a des 
questions qui ont ete posees a I'utilisateur et que le choix de I'utilisateur a et& 
correctement recueilli. Une application sans confiance ne peut pas simuler ce 
comportement. Le risque de cheval de Troie est done ecarte. - 

15 Si la verification par le serveur 1 de la requete censee indiquer I'accord 

de I'utilisateur montre qu'elle a ete transmise dans les limites appliquees aux 
applications sans confiance, cette requete n'est pas interpretee comme etant 
representative de I'accord de I'utilisateur. Ce refus du serveur peut 
optionnellement §tre notifie en retourau terminal. 

20 Naturellement, la question presentee a I'utilisateur peut appeler une 

reponse de tout type, plus riche que "oui/non". La question peut notamment 
prendre la forme d'un formulaire dans lequel plusieurs entrees seraient a 
renseigner par I'utilisateur. Dans ce cas, les differentes entrees renseignees 
par I'utilisateur peuvent etre transmises au serveur apres que le composant de 

25 confiance 8 a demande et obtenu une validation de la part de I'utilisateur. 

Dans la description qui precede, I'application sans confiance 4 genere 
elle-meme le texte de la question. Si on prefere que le serveur 1 genere le 
texte de la question, on peut par exemple proceder comme suit: 

- une application sans confiance 4 soumet au composant de confiance 8 
30 I'adresse d'un serveur 1 (par exemple une URL) et une requete 

appropriee a lui envoyer pour obtenir I'enonce de la question a poser; 
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- le composant de confiance 8 emet la requete via le reseau R afm de 
demander a ce serveur 1 I'enonce de la question. La requete est de 
preference passee par la couche de controle 5 afin de garantir qu'elle soit 
dans les limites autorisees pour les applications sans confiance 4; 

- le serveur 1 renvoie I'enonce de la question, en relation avec une 
reference a rappeler ulterieurement lors de la transmission de I'accord de 
I'utilisateur; 

- le composant de confiance 8 presente la question a I'utilisateur comme 
. precedemment; 

- I'utilisateur fait sa decision; 

- la decision de I'utilisateur est recueillie par le composant de confiance 8; 

- en cas d'accord, le composant de confiance 8 emet une requete vers le 
serveur 1 , cette fois-ci hors des limites imposees aux applications sans 
confiance, en incluant la reference de Tenonce et stipulant que 
I'utilisateur a bien donne son accord (la reference peut etre optionnelle, 
auquel cas le composant de confiance repete I'enonce de la question 
dans la requete transmise a cette etape; de fagon generate, il suffit que la 
question posee soit suffisamment identifiee dans le message transmis au 
serveur pour indiquer I'accord de I'utilisateur); 

- le serveur 1 valide la requete en verifiant qu'elle est bien regue hors des 
limites imposees aux . applications sans confiance, et repond a cette 
requite; 

- la reponse est transferee a ("application qui a initie la demande. 

Comme on s'est assure de passer la requite provenant directement de 
I'application sans confiance 4 par la couche de controle 5, le serveur 1 reste 
assure que les requetes hors limites qu'il regoit du composant de confiance 8 
resultent bien d'un accord explicite de I'utilisateur. 

Dans un mode de realisation particulier de I'invention, le terminal 
dispose d'une machine virtuelle Java, pouvant correspondre au module 6 dans 
I'illustration des figures 1 et 2. La machine virtuelle permet d'executer des 
applications telechargees ecrites dans le langage de programmation Java mis 




-13- 

au point par la societe Sun Microsystems, Inc. Toutes les instructions du 
langage Java sont executees par la machine virtuelle, qui fait appel aux 
fonctions systeme apres un certain contr6le. Pour les applications Java, on est N 
bien dans un environnement semi-ouvert puisqu'il n*y a pas d'appel sans 
5 controle aux fonctions systeme. 

L'application sans confiance 4 est alors ecrite en langage Java. 

Dans ce mode de realisation, les protocoles mis en jeu pour les 
echanges du terminal 2 sur le n§seau R sont les protocoles HTTP (RFC 1945 
("Request For Comments"), publiee en mai 1996 par I'lETF ("Internet 

10 Engineering Task Force")), TCP (RFC 793, IETF, septembre 1981) et IP (RFC 
791, IETF, septembre 1981). La limite appliquee aux applications sans 
confiance est qu'elles ne peuvent pas adresser de requetes vers les URL de 
type: "h.ttp://<serveur>/<chemin>/accord?<suite>", ou <serveur> 
est un nom de serveur quelconque, <chemin> est une suite de chaTnes de 

15 caracteres de la forme "repertoirejL/repertoire_2/.../repertoire/ii" 
et <suite> est une chatne de caracteres quelconque. Cette limite est bien sOr 
un exemple, n'importe quelle autre limite pouvant faire I'affaire. Le service est 
heberge par un serveur HTTP. « 

Le composant de confiance 8 peut alors etre implements dans la 
20 machine virtuelle Java par la classe UserConf irmation. II est accessible 
depuis les applications Java 4 par une fonction de classe: inputstream 
UserConf irmation. ask (String url, String question) dont le 
fonctionnement est le suivant. Lorsqu'une application sans confiance 4 appelle 
la fonction UserConf irmation. ask (String url, String question): 

25 - le composant de confiance 8 ouvre une fenetre ou bien prend le controle 

du terminal sur l'application en cours d'execution; 

- la question dont I'Snonce est donne par la chatne de caracteres 
"question" est affichee a I'ecran, et deux choix sont proposes a 
I'utilisateur, a savoir "ok" et "Annuler"; 
30 - si I'utilisateur donne son accord, en choisissant "ok": 
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• !e composant de confiance 8 envoie sur le reseau R la requete 
HTTP formee par la concatenation (i) de I'URL donnee en 
parametre ("url"), 00 de la chaTne "/accord? quest ion=", (Hi) 
de I'enonce de la question posee a I'utilisateur (encodee au 
format d'encodage dans I'URL x-www-urlencoded), et de la 
chaine "&reponseOK". Ce comportement n'est bien sur qu'un 
exemple qui correspond a la limitation appliquee aux requetes 
sortant des applications Java. Un serveur est assure par cette 
combinaison que les requetes envoyees a ce stade par le 
composant de confiance n'auraient pas pu etre envoyees par les 
applications Java, ce qui repond au besoin; 

• lorsque le composant de confiance 8 regoit ensuite la reponse du 
serveur 1 (ou une exception si le serveur n'est pas disponible), il 
retourne a I'application appelante 4 un objet inputstream 
permettant a celle application de connaTtre la reponse du serveur; 

- si I'utilisateur ne donne pas son accord, en choisissant "annuler": 

• le composant de confiance 8 renvoie une exception a I'application 
appelante 4. 

Pour illustrer ce mode de realisation particulier, on considere le cas ou 
le serveur gere un service de micropaiement effectuant des paiements en ligne 
pour le compte de I'utilisateur sur simple accord de ce dernier. Les paiements 
sont debites d'un compte correspondant a I'utilisateur. Lorsqu'il regoit un ordre 
de paiement, ce service veut done s'assurer que cet ordre est bien confirme 
par I'utilisateur, et n'est pas en provenance d'un programme Java mal 
intentionne qui n'aurait presente aucune question a I'utilisateur, ou bien qui lui 
aurait presente une question trompeuse. Ce service est bien entendu un 
exemple, n'importe quel autre sen/ice demandant I'accord de I'utilisateur 
pouvantetre realise grace, a cette technique (publication de documents, gestion 
de fichiers, messagerie, etc.) 

Dans cet exemple, le service de paiement controle le site web 
"paiement .com". Lorsqu'une application sans confiance souhaite proposer un 
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paiement a I'utilisateur, elle appelle la fonction userconf irmation.ask en 
lui dormant comme parametres: 

• comme URL: http .- //paiement . com/paiement 

• comme enonce de question: "Payer 1€ a Acme Co.?" 

5 Le composant de confiance 8 prend le contrdle du terminal 2, et 

demande a I'utilisateur "Payer l€ a Acme Co.? OK / Annu'ler". Si 
I'utilisateur choisit le lien "ok", le composant de confiance emet la requete 
"http : //paiement . com/paiement/accord?question=payer+l€+a+Ac 
me+co. ?&reponse=OK" et transmet la reponse du serveur a I'application 
10 appelante 4, en lui redonnant la main. 

Si I'utilisateur choisit le lien "Annuler", le composant de confiance 8 
n'emet aucune requete et retourne une exception a I'application appelante 4$ 

Si une application 4 tente de demander directement la page 
"http: / /paiement . com/paiement/accord?question=payer+l€+a+Ac 
15 me+Co.?&reponse=OK", cette requete est refusee par la limitation appliquee 
aux applications sans confiance. 

Comme autre illustration du precede selon I'invention, on considere le 
cas oD le serveur gere un service de commerce electronique. Dans le cadre 
d'un tel service, le client est amene a remplir un formulaire de commande. Ce 
20 formulaire est a envoyer selon la methode HTTP POST a I'adresse 
"http : // service . com/ commande". 

Le composant de confiance peut alors etre implements dans la 
machine virtuelle Java. II est accessible des applications Java par une fonction 
"UserConfirmation.askForm (String url, byte[] formulaire)". 

25 Lorsque cette fonction est appelee par une application Java 4, le 

composant de confiance 8: 

• affiche a I'ecran le formulaire contenu dans le tableau "formulaire" 
passe en parametre de la fonction. Ce formulaire est par exemple dans 
un format XML; 
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. laisse l'utilisateur remplir les champs du formulaire et lui demande de le 
valider en choisissant "ok" ou "Annuler" a la fin du formulaire; 

. envoie une requete HTTP POST lorsque l'utilisateur valide le formulaire, 
a I'URL "url+/accord?", cette requete contenant le formulaire qui a ete 
presente a l'utilisateur, ainsi que les donnees saisies par l'utilisateur dans 
les differents champs. 

Si une application Java sans conflance 4 tente d'acceder directement a 
I'adresse "url+/accord?", la requete sera refusee par la couche de controle. 

Par ailleurs, une application pourrait tenter d'induire en erreur 
l'utilisateur en lui faisant remplir un formulaire comportant les memes entrees 
que le formulaire authentique, mais avec des libelles differents. Cette attaque 
est egalement dejouee par le fait que le formulaire est transmis au serveur 1 
par le composant de confiance 8. De cette facon, le serveur 1 peut en effet 
verifier que le formulaire rempli par l'utilisateur est bien un formulaire legitime. 

On a pris pour clarifier I'expose un exemple simple de limitation 
imposee aux applications sans confiance, a savoir que certaines URL ne sont 
pas accessibles, ce qui est contr6le au moment de remission d'une requete. 
Neanmoins, n'importe quelle autre limitation serait acceptable. 

On peut notamment utiliser un blocage complet de tout acces au 
reseau R pour les applications sans confiance 4, un blocage selectif autorisant 
seulement les requetes vers le site web d'origine d'une application telechargee, 
etc. 

La limitation peut aussi se rapporter a un marquage specifique associe 
soit aux applications sans confiance 4, soit aux applications de confiance 3. 
Chaque requete issue d'une application sans confiance 4, emise sur le reseau 
R a destination du serveur 1 , est alors contrainte par la couche de controle 5: 
IM soit a inclure un marquage associe a la famille des applications sans 
confiance, 

121 soit a ne pas inclure un marquage associe a la famille des applications 
de confiance, ce marquage etant alors inclus dans certaines au moins 



p 
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des requetes emises sur le reseau R et issues (^applications de 
confiance. 

Dans ie cas /1/, le composant de confiance 8 n'appose pas le 
marquage dans les requetes emises pour indiquer I'accord de Putilisateur, ce 
5 qui assure au serveur 1 que cet accord provient bien de I'utilisateur. Le 
composant de confiance 8 peut en revanche marquer la requete emtse sur le 
reseau R pour obtenir I'enonce de la question a poser dans le cas oCi cet 
enonce n'est pas fourni directement par I'application 4. 

Inversement, dans le cas /2/ f le composant de confiance 8 appose le 
10 marquage dans les requetes emises pour indiquer raccord de I'utilisateur, et le 
cas echeant il ne marque pas la requete 6mise sur le reseau R pour obtenir 
I'enonce de la question a poser. 

. 1 

Dans I'exemple oD le composant de confiance 8 fait partie. .:' d'une 
machine virtuelle Java 6, le marquage du cas IV consiste par exemple en ce 
15 que le champ d*en-t§te "User-Agent" des requetes HTTP (cf. section 10.15 de 

V'- 

la RFC 1945 precitee) contienne une chame specifique telle que 
"Application sans confiance: VM Java 1.2" qui indique par sa 
presence que la requete n'est pas en provenance d'une application de 
confiance. Une mention inverse peut etre prevue dans le cas /2/. 

20 
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REVENDICATIONS 

1. Procede de communication entre une premiere unite (2) et une 

seconde unite (1) par I'intermediaire d'un reseau de telecommunication (R), 
dans lequel la premiere unite comporte une premiere famille d'applications (4) 
et une seconde famille d'applications (3) ayant des capacites de 
communication sur le reseau au-dela des capacites de communication des 
applications de la premiere famille, le procede comprenant les etapes 
suivantes: 

/a/ un composant de confiance (8) appartenant a la seconde famille 
d'applications obtient I'enonce d'une question a poser a un utilisateur 
de la premiere unite dans le cadre de I'execution d'une application (4) 
de la premiere famille; 

Ibl le composant de confiance presente la question par i'intermediaire 
d'une interface d'utilisateur (9) et recueille une reponse de I'utilisateur; 
et 

Id pour au moins un type de reponse de I'utilisateur, le composant de 
confiance transmet a la seconde unite, par I'intermediaire du reseau, 
au moins un message identifiant la question presentee et indiquant la 
reponse recueillie, ledit message etant transmis dans des conditions 
inaccessibles aux applications de la premiere famille. 

2. Procede selon la revendication 1 , dans lequel la question presentee 
est identifiee dans le message de I'etape Id en incluant I'enonce de la question 
dans ledit message. 

3. Procede selon la revendication 1 ou 2, dans lequel pour au moins un 
autre type de reponse traduisant un refus de I'utilisateur par rapport a la 
question presentee, le composant de confiance (8) indique le refus a ladite 
application (4) de la premiere famille. 
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4. Proc6de selon la revendication 3, dans lequel pour le type de 

reponse traduisant un refus de Putilisateur par rapport a la question presentee, 
le composant de confiance (8) ne transmet pas a la seconde unite (1) le 
message de Petape loL 

5 5. Procede selon Tune quelconque des revendications precedentes, 

dans lequel la seconde unite (1) valide la reponse de Putilisateur a reception du 
message transmis a I'etape Id en s'assurant qu'il a bien ete transmis dans des 
conditions inaccessibles aux applications de la premiere famille. 

6. Procede selon la revendication 5, dans lequel apres validation de la 
10 reponse de Putilisateur, la seconde unite (1) retourne un message de reponse 

au composant de confiance (8) par Pintermediaire du reseau (R). ^ 

r 

7. Procede selon la revendication 6, dans lequel le composant de 
confiance (8) indique a ladite application (4) de la premiere famille la teneur du 
message de reponse regu de la seconde unite (1), 

15 8. Procede selon Tune quelconque des revendications prec&Jentes, 

dans lequel Penonce de la question est indique directement au composant de 
confiance (8) a I'etape /a/ par ladite application (4) de la premiere famille. 

9. Procede selon la revendication 8, dans lequel ladite application (4) 
de la premiere famille indique une adresse de la seconde unite (1) avec 

20 Tenonce de la question a I'etape /a/. 

10. Procede selon Pune quelconque des revendications 1 & 7, dans 
lequel Petape /a/ comprend les sous-etapes suivantes: 

/a1/ ladite application (4) de la premiere famille indique au composant de 
confiance (8) une adresse de la seconde unite (1) ainsi qu'une 
25 requete a soumettre pour obtenir Penonce de la question de la part de 

la seconde unite; 
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la2l le composant de confiance emet la requete a I'adresse indiquee, par 

I'intermediaire du reseau (R); 
/a3/ le composant de confiance recupere I'enonce de la question dans une 

reponse a la requete retournee par la seconde unite par 

I'intermediaire du reseau. 

1 1 . Precede selon la revendication 10, dans lequel la requete est emise 
par le composant de confiance (8) a la sous-etape /a2/ dans des conditions 
accessibles aux applications de la premiere famille. 

12. Precede selon la revendication 1 0 ou 1 1 , dans lequel la reponse a la 
requete retournee par la seconde unite (1) inclut en outre une reference que le 
composant de confiance (8) memorise puis insere dans le message transmis a 
I'etape id pour identifier la question presentee. 

13. Precede selon Tune quelconque des revendications precedentes, 
dans lequel ladite application (4) de la premiere famille est un programme ecrit 
en langage Java et le composant de confiance (8) est incorpore a une machine 
virtuelle Java (6) dont est pourvue la premiere unite (2). 

14. Precede selon Tune quelconque des revendications precedentes, 
dans lequel les applications (3) de la seconde famille ont la capacite d'acceder, 
par I'intermediaire du reseau (R), a au moins une URL associee a la seconde 
unite (1) et inaccessible aux applications (4) de la premiere famille. 

15. Precede selon Tune quelconque des revendications 1 a 13, dans 
lequel les applications (4) de la premiere famille ne sont pas capables 
d'acceder au reseau (R). 

16. Precede selon Tune quelconque des revendications 1 a 13, dans 
lequel les applications (4) de la premiere famille ont la capacite, dans un 
protocole de transfer! determine, de n'acceder qu'a un seul site distant ne 
comportant pas la seconde unite (1). 
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17. Procede selon I'une quelconque des revendications 1 a 13, dans 

lequel on contraint chaque requete issue d'une application (4) de la seconde 
famllle, emise sur le reseau (R) a destination de la seconde unite (1), a inclure 
un marquage associe a la seconde famille duplications (3). 

5 18. Procede selon I'une quelconque des revendications 1 a 13, dans 

lequel on contraint chaque requete issue d'une application (4) de la seconde 
famille, emise sur le reseau (R) a destination de la seconde unite (1), a ne pas 
inclure un marquage associe a la premiere famille, ledit marquage etant inclus 
dans certaines au moins des requites emises sur le reseau et issues 

10 d'applications (3) de la premiere famille. 

19. Procede selon la revendication 17 ou 18, dans lequel les requites 
comprennent des requetes HTTP, et le marquage est insere dans les en-tetes 
des requetes HTTP. 

20. Composant logiciel de confiance pour une premiere unite (2) 
15 capable de communiquer avec une seconde unite (1) par Hntermediaire d'un 

reseau de telecommunication (R), la premiere unite comportant une premiere 

r- 

famille d'applications (4) et une seconde famille d'applications (3) ayant des 
capacites de communication sur le reseau au-dela des capacites de 
communication des applications de la premiere famille, le composant de 
20 confiance (8) appartenant a la seconde famille d'applications et incluant des 
instructions pour commander les etapes d'un procede selon Tune quelconque 
des revendications 1 a 19 lors d'une execution du composant dans la premiere 
unite. 



25 



21. Terminal de communication, incorporant un composant logiciel de 

confiance selon la revendication 20 pour communiquer avec une unite distante 
(1) par Pintermediaire d'un reseau de telecommunication (R). 
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